在台灣要縮一條網址，很多人第一個想到的是 reurl。它免費，而且功能不算少。

也不止它，短網址服務的輪子多到滾來滾去，為什麼我還要自己再做一個輪子？

我做的那個輪子叫 toui。但今天要講的是它還不存在的時候，我看著 reurl，盤算自己憑什麼再做一個。

先看看免費可以做到什麼程度

reurl 一進站就是一個輸入框，貼上網址、按下去，短網址就出來了。旁邊還附一張 QR Code。

行銷人追成效要用的 utm，它也有提供，utm_source、utm_medium、utm_campaign、utm_term、utm_content 五個欄位都在，填完會幫你把參數組進網址裡。登入之後可以看每條連結被點了幾次。

更讓人意外的是它有 API，申請之後，一天有一百次呼叫的額度。

它靠廣告模式營運，進站免不了有點東掛一塊、西掛一塊的感覺，但這一點我覺得沒什麼好抱怨，甚至是很合理的策略，你要嘛跟使用者收錢，要嘛跟廣告主收錢，網站開在那裡作服務，總是要有營收。

不過有一個地方讓我有點介意，至少從我開始做 toui 到現在，它的分享預覽區塊一直是壞的。圖片是破圖，描述欄是不知道是什麼作用的 CSS 碎片。即使是 google.com 這麼簡單的網站抓到也是錯的，所以可以排除是特定網站的問題。後面我會回來講這件事代表的意義，先繼續講它正常的地方。

縮一條 https://google.com，中間的 preview 區塊：圖片破圖，描述欄抓回來的是 CSS

免費也有到不了的地方

我第一次真正感受到 reurl 的普及，是有位朋友他們公司每天都要用短網址，也接了 API 來加速作業。一天一百次的額度，他們經常撞到。

那個額度對一般人綽綽有餘，對一間每天都要發連結的公司就是天花板。

且不論我朋友用克難方式解決了他們公司的使用情境，那卻不是每一家企業或用戶都能接受。還有其他的問題存在，這裡可以拿我自己以前的經驗來說。

我第一次寫短網址服務，是為自家公司做的

當時要處理的問題有四個：

1. 網址太長：某些外部來的網址，參數長度很誇張
2. 短網址服務紛紛開始收費、開始卡限制
3. 品牌與形象：要讓人一眼看出這條連結是官方發的
4. 語義化的短碼：不是一串亂碼，是看得懂的字

評估之後覺得不難處理，所以我們就自己做了。AWS 的 API Gateway、Lambda、DynamoDB 三樣神器，組出一套低成本、回應又快的架構，再補一個後台就差不多了。這幾年一路修修改改，加過批次上傳、加過 QR Code，但需求大致就是這麼簡單。

現在回頭看有個特別值得玩味的地方，即便我們想用免費的 reurl，後面兩點它沒有提供，不是做不到，是沒有動機。一個靠廣告養的免費服務，沒有任何理由幫你把它自己的品牌從網址上拿掉，也沒有理由把「好記的字」這種稀缺資源免費送給你。

於是我想，那我來做一個吧

就像上一篇說的，我已經用 Claude Code 做過好幾個 side project，覺得短網址這個服務在開發上還算輕量，各種條件都適合作開發與營運。

想說看看別人是怎麼做服務的，那時我在 Google 搜「短網址」，排在最前面的就是 reurl。就我的感受而言，它的介面有點雜亂，配置也不太像現在的網站風格，另外廣告也多；如果我能把介面做得更好用，再把朋友撞到的那個額度放開，是不是就會有人願意付錢？

做了一點技術研究之後，發現放在 Cloudflare 上營運可以把成本壓得很低。登入我不想搞複雜，Google 登入再加一個給非 Google 用戶的管道就好（一開始選了 Resend，後來換掉了，之後細說）。既然是要收費的，金流是個大問題，國內的金流系統比起便利往往更重視防弊，於是我把眼光轉向國外，選了對開發者很友善、評價也不錯的 Lemon Squeezy（後來也換掉了，又是另一個故事）。

程式跟視覺都交給 Claude Code 包辦，幾個星期後初版差不多完成，開始準備上線。

當時台灣還有其他短網址服務，國外當然也有更多，但我一開始只盯著搜尋結果最前面那個。就在準備行銷的時候，才開始認真看了一輪國外的短網址服務，發現自己好像落後了一個世代，尤其在短網址行銷相關的功能。接下來那幾天拼命追補一個現代短網址服務該有的功能，進階分析整套在一天之內補完，把國家、來源、裝置的資料串接起來，影響的範圍從資料聚合、資料規劃到使用介面；隔幾天補上社群分享的預覽圖；還有尚未完成的 i18n 建置（支援中、英雙語），這點也很重要，一開始我就想把 toui 的市場放在全世界。

這一連串程式的追趕跑跳碰都補完，toui 才正式推出上線，不得不感謝 Claude Code 的威力。

順便說一件我後來才想通的事

Claude Code 做得太快，東西一直長出來，那種順暢感會讓人以為問題都解決了——Resend 跟 Lemon Squeezy 這兩個選擇，就是在那種順暢感裡定下來的。

而這其實是同一件事的另一面。以前決定要不要做一個 side project，第一個問題是「我做不做得出來」。

現在那個問題幾乎不用問了。所以真正的問題應該變成「這東西該不該存在、誰會為它付錢」。

那些需求，為什麼一直沒被滿足

回頭看我公司當年那四個問題，加上朋友撞到的那個額度，它們的共同點是成本會隨著使用量長大，但廣告收入不會。

最清楚的例子就是 API。廣告收入來自「有多少人進站」，可是接 API 的人平常根本不會進站，他們直接打 endpoint，看不到任何廣告。對一個靠廣告養的服務來說，重度 API 使用者是純成本、零收入。所以一天一百次不是小氣，那個數字剛好落在不虧的位置。

其他幾項也一樣。把品牌從網址上拿掉，等於把自己的曝光讓出去；把「好記的字」發給你，那個字就永遠不會再回來；多留一年的點擊明細，儲存費用就多一年。

所以那些需求不是沒人想到，是在廣告模式底下做了會虧。reurl 沒做不是能力問題，是它的收入結構撐不起來。

說穿了，誰付錢，服務就為誰優化。

廣告主付錢，服務往流量、版位、曝光的方向長；使用者付錢，服務往額度、品牌、可靠度的方向長。這不是誰比較有良心，是收入從哪裡來，決定了它會為誰解決問題。

前面那個壞了幾個月的預覽功能，從這個角度也就說得通了。修它對廣告收入沒有任何幫助；但如果那是一個要收月費的服務，同一個壞掉的功能就是退訂的理由。優先序不同，不是能力不同。

所以我當時最大的錯，不是把介面想得太簡單，是拿一個免費服務當標竿，它跟我要做的東西，從收入結構上就不是同一件事。

所以，為什麼還要自己做一個？

答案不是「我想賺錢」，也不是「因為它不夠好」。

是因為我想解的那些問題——企業要自己的品牌、要好記的短碼、要用得夠多的額度——只有在「使用者付錢」的結構下才做得起來。要做那些事，服務的收入就必須來自使用者，而不是來自廣告。

一旦把它當成一門生意，免費方案就不再是「試用版」，而是產品的一部分，免費的人拿到什麼、付費的人多拿什麼、界線畫在哪裡，全都得重新想過。

至於一門生意除了「收費」之外還需要什麼，當時我以為經過一番修補之後有模有樣，toui 有答案了，因此公開推出，我第一個收費的服務就這樣上線。

但功課還在後面。